UA Part 9: Alarms and Conditions - Annex B (informative)Examples

Errata exists for this version of the document.

B.1 Examples for Event sequences from Condition instances

The following examples show the Event flow for typical Alarm situations. The tables list the value of state Variables for each Event Notification.

B.1.2 Server maintains current state only

This example is for Servers that do not support previous states and therefore do not create and maintain Branches of a single Condition.

Figure B.1 shows an Alarm as it becomes active and then inactive and also the acknowledgement and confirmation cycles. Table B.1 lists the values of the state Variables. All Events are coming from the same Condition instance and therefore have the same ConditionId.

Figure B.1 – Single state example

Table B.1 – Example of a Condition that only keeps the latest state

EventId	BranchId	Active	Acked	Confirmed	Retain	Description
-*)	NULL	False	True	True	False	Initial state of Condition.
1	NULL	True	False	True	True	Alarm goes active.
2	NULL	True	True	False	True	Condition acknowledged Confirm required
3	NULL	False	True	False	True	Alarm goes inactive.
4	NULL	False	True	True	False	Condition confirmed
5	NULL	True	False	True	True	Alarm goes active.
6	NULL	False	False	True	True	Alarm goes inactive.
7	NULL	False	True	False	True	Condition acknowledged, Confirm required.
8	NULL	False	True	True	False	Condition confirmed.
) The first row is included to illustrate the initial state of the Condition. This state will not be reported by an Event*.

B.1.3 Server maintains previous states

This example is for Servers that are able to maintain previous states of a Condition and therefore create and maintain Branches of a single Condition.

Figure B.2 illustrates the use of branches by a Server requiring acknowledgement of all transitions into Active state, not just the most recent transition. In this example no acknowledgement is required on a transition into an inactive state. Table B.2 lists the values of the state Variables. All Events are coming from the same Condition instance and have therefore the same ConditionId.

Figure B.2 – Previous state example

Table B.2 – Example of a Condition that maintains previous states via branches

EventId	BranchId	Active	Acked	Confirmed	Retain	Description
a)	NULL	False	True	True	False	Initial state of Condition.
1	NULL	True	False	True	True	Alarm goes active.
2	NULL	True	True	True	True	Condition acknowledged requires Confirm
3	NULL	False	True	False	True	Alarm goes inactive.
4	NULL	False	True	True	False	Confirmed
5	NULL	True	False	True	True	Alarm goes active.
6	NULL	False	True	True	True	Alarm goes inactive.
7	1	True	False	True	True b)	Prior state needs acknowledgment. Branch #1 created.
8	NULL	True	False	True	True	Alarm goes active again.
9	1	True	True	False	True	Prior state acknowledged, Confirm required.
10	NULL	False	True	True	True b)	Alarm goes inactive again.
11	2	True	False	True	True	Prior state needs acknowledgment. Branch #2 created.
12	1	True	True	True	False	Prior state confirmed. Branch #1 deleted.
13	2	True	True	True	False	Prior state acknowledged, Auto Confirmed by system Branch #2 deleted.
14	NULL	False	True	True	False	No longer of interest.
a) The first row is included to illustrate the initial state of the Condition. This state will not be reported by an Event. Notes on specific situations shown with this example: If the current state of the Condition is acknowledged then the Acked flag is set and the new state is reported (Event #2). If the Condition state changes before it can be acknowledged (Event #6) then a branch state is reported (Event #7). Timestamps for the Events #6 and #7 is identical. The branch state can be updated several times (Events #9) before it is cleared (Event #12). A single Condition can have many branch states active (Events #11) b) It is recommended as in this table to leave Retain=True as long as there exist previous states (branches).

B.2 AddressSpace examples

This Clause provides additional examples for the use of HasNotifier, HasEventSource and HasCondition References to expose the organization of areas and sources with their associated Conditions. This hierarchy is additional to a hierarchy provided with Organizes and Aggregates References.

Figure B.3 illustrates the use of the HasCondition Reference with Condition instances.

Figure B.3 – HasCondition used with Condition instances

In systems where Conditions are not available as instances, the ConditionSource can reference the ConditionTypes instead. This is illustrated with the example in Figure B.4.

Figure B.4 – HasCondition reference to a Condition type

Figure B.5 provides an example where the HasCondition Reference is already defined in the Type system. The Reference can point to a Condition Type or to an instance. Both variants are shown in this example. A Reference to a Condition Type in the Type system will result in a Reference to the same Type Node in the instance.

Figure B.5 – HasCondition used with an instance declaration